home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1016 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  7.6 KB

  1. Path: fido.asd.sgi.com!austern
  2. From: ajay@lehman.com (Ajay Kamdar)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: sample auto_ptr template
  5. Date: 09 Apr 1996 09:58:11 PDT
  6. Organization: Lehman Brothers, Inc.
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <4kcr2d$p03@jabba.lehman.com>
  9. References: <009A04DA6A831C40.49800EAC@ittpub.nl> <bill-0504961003150001@bgibbons.vip.best.com> <4k4noe$igl@jabba.lehman.com> <bill-0804960932250001@bgibbons.vip.best.com>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. X-Original-Date: 9 Apr 1996 01:03:09 -0400
  12. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  13.     iQBVAwUBMWqXJEy4NqrwXLNJAQFsEwH/Z0BxE13PIH/TYYKRnaOJFkcxIcmKf7l2
  14.     nRQjAUHQ0AIPjuYV8QEfoavJjyiWfXI4MDb6t+dZTNLxKcDLHgKe3Q==
  15.     =F0V4
  16. Originator: austern@isolde.mti.sgi.com
  17.  
  18. In article <bill-0804960932250001@bgibbons.vip.best.com>,
  19. Bill Gibbons <bill@gibbons.org> wrote:
  20. >In article <4k4noe$igl@jabba.lehman.com>, ajay@lehman.com (Ajay Kamdar) wrote:
  21. >
  22.            [ snip ]
  23. >> 
  24. >> What's wrong with this? It doesn't require copy semantics
  25. >> for auto_ptr. Yet both the caller and the callee
  26. >> are exception safe and there is no loss of clarity.
  27. >
  28. >The problem is that it requires handling the raw pointer.
  29. >Any time you transfer ownership by using release() to extract
  30. >the raw pointer and then later use the raw pointer to
  31. >construct another auto_ptr, there is a window where there is
  32. >no exception safety.
  33. >
  34.  
  35. You didn't say whether the example I gave was exception
  36. safe or not. To reiterate the main points of the example
  37.    + The caller directly initializes an auto_ptr with
  38.      the returned value from the calee.
  39.      auto_ptr<X> ptr(get_X());
  40.  
  41.    + The callee releases the pointer from it's own
  42.      auto_ptr in it's return statement.
  43.  
  44. No copy constructors are involved in the return. Hence
  45. there is no possibility of an exception thrown from
  46. a user defined copy constructor. So which window are
  47. you referring to during which there is no exception
  48. safety? I claim there is none.
  49.  
  50. >Of course you can carefully craft the code to make sure that
  51. >no exceptions can be propagated during the window.  But there
  52. >are two problems:
  53.  
  54. The example I gave is straight forward C++ programming; no
  55. contortions or careful coding are required. The coding
  56. pattern is simple enough that even junior programmers can
  57. be taught to follow it easily.
  58.  
  59. Many other more useful extensions have been voted down by
  60. the commitee on the grounds that the requested extension
  61. could be implemented by existing mechanisms within the
  62. language, even if those techniques required a fair
  63. amount of work for the programmer. That stance cannot be
  64. more applicable than in the case of the copy semantics
  65. of auto_ptr -- there is simply no need for such semantics
  66. because identical exception safety can be achieved by
  67. a simple coding pattern.
  68.  
  69.  
  70. >  (1) The maintainers of the code may not be as careful about
  71. >      exception safety.  When everything is handled by
  72. >      auto_ptr the risk of bugs creeping in is smaller.  Such
  73. >      bugs are very difficult to find by testing.
  74.  
  75. Let's analyze which code is more difficult to maintain
  76. and difficult to debug -- one using the copy semantics
  77. of auto_ptr or one wihout copy semantics of auto_ptr.
  78.  
  79.   With copy semantics
  80.   ===================
  81.      If the copy ctor of auto_ptr taking a const auto_ptr&
  82.      releases its raw pointer by casting away const,
  83.      a programmer can accidentaly "lose" the raw pointer from
  84.      within an auto_ptr -- even if the programmer was working
  85.      with a const auto_ptr. This occurrs because auto_ptr
  86.      violates const correctness and releases the raw pointer
  87.      from the raw object.
  88.  
  89.      If the copy ctor of the auto_ptr taking a const auto_ptr&
  90.      takes ownership of the raw pointer by casting away const
  91.      and setting a flag (the latest proposal), the programmer
  92.      can end up with a dangling pointer in the original
  93.      auto_ptr if the new auto_ptr destructs first and deletes
  94.      the raw pointer.
  95.  
  96.      It is possible that even extensive testing may not
  97.      uncover such a problem on a less frequently traversed
  98.      path in the code. Even if the path is traversed during
  99.      testing, an error may or may not be generated when using
  100.      the dangling pointer. Hence it is very possible that the
  101.      error might escape it to production code.
  102.  
  103.   Without copy semantics of auto_ptr
  104.   ==================================
  105.     By eliminating any surprises due to the standard
  106.     auto_ptr violating const correctness and leaving
  107.     behind dangling pointers, program correctness is
  108.     actually *improved*.
  109.  
  110.     But for the moment assume that even the simple pattern
  111.     of using auto_ptr (release() on return in callee,
  112.     direct initialization of auto_ptr in caller) is
  113.     not followed correctly in some situation. Two major
  114.     scenarios are possible:
  115.        1. The error happens on a frequently travesed path
  116.       in the code, resulting in frequent ommission to
  117.       call delete.
  118.  
  119.       In such situations, any of the many good leak
  120.       detectors on the market will show the error
  121.       during testing. The error will be fixed
  122.       before it reached production.
  123.  
  124.       2. The error is rare enough that it occurs only in
  125.      production.
  126.  
  127.      By definition, the error is rare. So the application
  128.      will lose some resource each time. In practice,
  129.      each occurence of a failure to delete a resource is
  130.      not disastorous on its own, and the application will
  131.      go on.
  132.  
  133.  
  134. So which one is better for the C++ programmer? An approach
  135. which can lead to disastorous surprises at run-time
  136. (auto_ptr with copy semantics approach) definitely does
  137. not look the right choice under any stretch of imagination.
  138.  
  139.  
  140. >  (2) The interface of get_X does not implicitly document
  141. >      that the returned pointer refers to an object which
  142. >      should be automatically deleted on an exception.
  143.                                ^^^^^^^^^^^^^^^^^^^^^^^
  144.  
  145. Now we are getting close to what I firmly believe is the
  146. real driving reason behind the push for auto_ptr to
  147. have copy semantics.
  148.  
  149. Note that in the above quoted text, the reference to
  150. exceptions in "deleted on an exception" is irrelevant.
  151. In this case, the caller must always delete the ptr
  152. allocated by the callee() -- exception or no exception.
  153. Hence the use of auto_ptr in this case has nothing to
  154. do with exception safety. But it has everything to do
  155. with trying to replace documentation accompanying
  156. get_X() saying that the caller must delete the pointer.
  157.  
  158. In isolation, it is a good goal to replace comments
  159. which prescribe certain behavior with code constructs
  160. which automatically take care of the issue. By
  161. giving copy semantics to auto_ptr, the need to
  162. document transfer of ownership of pointer is sourght
  163. to be eliminated. I firmly believe that *this* is the
  164. real reason behind the copy semantics of auto_ptr, with
  165. exception safety only a peripheral issue at best. 
  166. Unfortunately, it is abundantly clear that this attempt
  167. at replacing documentation by giving auto_ptr copy
  168. semantics has pretty high costs.
  169.  
  170. I strongly urge those who can do something about this
  171. (those on the committee) to step back and separate
  172. the wheat from the chaff. Don't make auto_ptr harder
  173. to use for *all* C++ programmers by allowing it to
  174. have copy semantics. Make a separate class
  175. (taligent_ptr) which has the copy semantics for
  176. those who *choose* to use it, rather than forcing
  177. everyone to program with an unfortunate choice.
  178. -- 
  179. Ajay Kamdar        |    Email: ajay@lehman.com    |    Standard Disclaimer 
  180. Lehman Brothers    |    Phone: (201) 524-5048     |
  181. ---
  182. [ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
  183.                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  184.   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  185.   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  186.   Comments? mailto:std-c++-request@ncar.ucar.edu 
  187. ]
  188.